Technical Field
This disclosure relates generally to web application security and, in particular, to ensuring secure transfer of a web application's client persistent state information to a new domain upon receipt of an authentic HTTP redirect.
Background of the Related Art
One way that computers interact via networks such as the Internet is using the HyperText Transfer Protocol (HTTP) open standard designed by the World Wide Web Consortium (W3C) and standardized as Internet Engineering Task Force (IETF) RFC 2616. It is an intentionally simple and open protocol that is implemented across many heterogeneous computer systems.
A web application often needs to modify its URL structure, e.g., to point to a new domain. When the web application has active users, however, the modification of URL structure is a troublesome task. The most difficult aspect is making sure that, even if URLs change, user impact is minimal. In particular, it is important that URLs are preserved in user clients (e.g., bookmarks in web browsers, URLs in feed readers and other rich-clients that use REST-based APIs, and the like) and continue to work for at least some transition period following the change. Typically, this goal is achieved by using HTTP redirects (from an old to a new location). There are two (2) main types of redirects: temporary, when the client is instructed to temporarily use another location (e.g., for a login page or a resource), and permanent, when a resource (e.g., a Web application's URL domain structure) changes permanently. As is well-known, these redirects are done through HTTP response codes, respectively, an HTTP 302 (temporary) and an HTTP 301 (permanent), which are returned from a web application to a requesting user-agent, such as a Web browser.
The HTTP specification (RFC 2616) defines that on permanent redirection (the HTTP 301) “clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible.” Practically, however, clients typically ignore (some purposefully) this requirement and do not update their URL references for HTTP 301 redirection. The main reasons for this behavior are usability and security problems. Thus, for example, consider a pay-per-use internet provider (e.g., at an airport or hotel), which providers often send the HTTP 301 redirect code incorrectly. If a browser updates links for this redirection, those links would be permanently changed to the incorrect location (and thus broken). In another example, if a browser updates URIs in response to an HTTP 301, malicious open wireless hotspots or proxies would gain the ability to permanently re-link a user's bookmarks or application URLs, thus expanding the scope of phishing attacks. Because of these and other similar problems, the current default behavior of user-agents is to ignore the RFC and not re-link.
It is also known that, as a result of interactions between a web application and an application server, so-called web application client state information (such as form elements, cookies, passwords and the like) that is associated with the client-application server interaction, is stored. When a web application moves to a new domain (such as indicated via a permanent HTTP redirect), this value of this state information in effect is lost. Users need to enter the information again and/or remove obsolete data stored for the old application server domain. In addition, all persistent cookies that locally cache a user's state information are not reflected in the new server domain. As a consequence, and despite the authenticity of the redirect, the user may have difficulty interacting with the new (redirected) application server domain in an automated and/or seamless manner.